CI follow-up: Acceptance (oceanbase) failed before its scenarios began, during Docker uv sync, because the locked pydantic-core wheel returned HTTP 403 from the Tsinghua PyPI mirror. This is unrelated to the README changes.

The same unmodified lockfile later succeeded in #1311: its OceanBase job freshly downloaded pydantic-core in centralus, while the failed #1309 job ran in westus3. This indicates region/IP-dependent mirror availability rather than a test or dependency-version regression.

#1310 provides the reliability hardening by refreshing the lockfile to official PyPI URLs; its full CI, including both acceptance jobs, is green.

Evidence: failed job https://github.com/oceanbase/powercontext/actions/runs/32486415491/job/96784021364; successful later download https://github.com/oceanbase/powercontext/actions/runs/32507898779/job/96852286657.

Follow-up to @AlexStocks's request in #1259:
#1259 (comment)

This PR exposes Pi as a fifth official integration in the README integrations section.

The distinct Pi note is intentional and follows the actual install paths:

• The shared Quick Start pins the CLI and host setup commands to v0.0.2, while the v0.0.2 integrations tree contains no pi package.
• Pi requires the native package at integrations/pi/plugins/powercontext and invokes Pi's install command (implementation); it is wired as its own setup pi workflow (command).
• Consequently, the Pi command deliberately uses a ref that includes the package (README); showing setup pi --ref v0.0.2 in the shared Quick Start would fail.

Suggested follow-up: once a tagged release includes Pi, move its install command into the shared Quick Start with that same tag. Keep the detailed native-package behavior and configuration in Configure Pi.